Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@assets/optional/kube-state-metrics/02-clusterrole.yaml`:
- Around line 6-22: The ClusterRole currently grants cluster-wide list/watch on
"secrets" in the resources block; remove "secrets" from that resources list in
the ClusterRole manifest (or move it into a separate opt-in ClusterRole/Role
bound only where secret metrics are explicitly enabled) so the
kube-state-metrics workload no longer has cluster-wide secret read access;
update any docs/values that toggle secret metrics to clearly opt-in if you
reintroduce a separate role.

In `@assets/optional/kube-state-metrics/04-deployment.yaml`:
- Around line 106-111: The manifest pins kube-state-metrics to control-plane
nodes via the nodeSelector (kubernetes.io/os: linux +
node-role.kubernetes.io/master) and a matching toleration; remove the
nodeSelector and the tolerations block from the Deployment so the workload is
not forced onto master/control-plane nodes (or if a softer preference is
required, replace with a preferredDuringSchedulingIgnoredDuringExecution
nodeAffinity targeting non-control-plane nodes instead of a hard
nodeSelector/toleration).
- Around line 38-41: The securityContext blocks (securityContext in the
container spec) are missing explicit capability drops; update each container's
securityContext to include capabilities.drop: ["ALL"] and then add back only any
strictly required capabilities via capabilities.add if needed (i.e., modify the
existing securityContext entries where allowPrivilegeEscalation,
readOnlyRootFilesystem, runAsNonRoot are set); apply the same change to the
other container securityContext occurrences in this file so all containers
explicitly drop all capabilities and only re-add minimal required ones.
- Around line 25-105: The pod is missing liveness/readiness probes and resource
limits for all three containers (kube-state-metrics, kube-rbac-proxy-main,
kube-rbac-proxy-self); for each container add a resources.limits stanza (e.g.
kube-state-metrics limits cpu/memory higher than requests; kube-rbac-proxy-main
and kube-rbac-proxy-self likewise) and add readinessProbe and livenessProbe
entries: for kube-state-metrics use an HTTP GET to port 8081 path /metrics (or
/healthz if preferred) and for kube-rbac-proxy-main/self use HTTPS HTTPGet
probes pointing to their secure-listen ports (8443 and 9443) with appropriate
scheme: HTTPS and path /readyz or /healthz, plus reasonable
initialDelaySeconds/periodSeconds/timeoutSeconds values; place these probes and
limits under the corresponding container blocks (identified by name:
kube-state-metrics, kube-rbac-proxy-main, kube-rbac-proxy-self).

In `@assets/optional/metrics-server/00-namespace.yaml`:
- Around line 5-9: The namespace-level pod security labels
pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, and
pod-security.kubernetes.io/warn are set to privileged and must be removed from
the namespace manifest to avoid opt-out of baseline/restricted controls; delete
those three labels from the namespace YAML and instead apply the exception only
to the specific workload by adding the equivalent labels/annotations on the
Deployment/DaemonSet/Pod manifest(s) for the metrics server or bind a targeted
ServiceAccount to a custom/restricted SCC (or cluster-scoped
SecurityContextConstraints) so only that workload runs with elevated privileges
rather than the entire openshift-monitoring namespace.

In `@assets/optional/metrics-server/05-deployment.yaml`:
- Around line 91-96: The manifest currently pins the pod to control-plane nodes
via the nodeSelector and tolerations entries (nodeSelector, tolerations, key:
node-role.kubernetes.io/master); remove these fields so the Deployment no longer
hard-requires scheduling on master/control-plane nodes, or replace them with a
non-mandatory soft constraint (e.g.,
preferredDuringSchedulingIgnoredDuringExecution style affinity) if you need a
preference—ensure no direct reference to node-role.kubernetes.io/master or
control-plane remains in the Deployment spec.
- Around line 57-60: The container spec currently only sets resource requests
(resources.requests.cpu and resources.requests.memory); add corresponding
resource limits by adding a resources.limits block with both cpu and memory
(e.g., limits.cpu and limits.memory) for the same container entry so the pod
cannot overconsume under pressure—update the resources section in the Deployment
container spec (the resources field under the container definition in this YAML)
to include limits for cpu and memory matching your expected upper bounds.
- Around line 61-63: The manifest's securityContext currently sets
allowPrivilegeEscalation and readOnlyRootFilesystem but omits runAsNonRoot and
capability drops; update the securityContext block (the same object containing
allowPrivilegeEscalation and readOnlyRootFilesystem) to set runAsNonRoot: true
and add capabilities: drop: ["ALL"] (and only add back any specific capabilities
if the container truly needs them), ensuring the hardening is enforced in the
deployment spec.

In `@assets/optional/node-exporter/02-clusterrole.yaml`:
- Around line 16-22: The ClusterRole currently grants access to the built-in
privileged SCC by listing resourceNames: - privileged for
securitycontextconstraints; replace this by creating and referencing a custom,
minimal SCC (e.g., node-exporter-scc) that only allows the specific host
namespaces and capabilities the DaemonSet requires, then update the
ClusterRole/RoleBinding to reference resourceNames: - node-exporter-scc (or the
custom SCC name) instead of privileged; ensure the ServiceAccount used by
node-exporter is the subject of the binding and that the custom SCC limits
capabilities, hostPID, hostNetwork, hostPath and any other host access to the
minimum necessary.

In `@assets/optional/node-exporter/04-daemonset.yaml`:
- Around line 25-26: The DaemonSet currently sets hostPID: true which
unnecessarily broadens the pod's privileges; remove the hostPID: true entry from
the Pod spec (spec.template.spec.hostPID) so the pod does not join the host PID
namespace unless a collector explicitly requires it, and verify the exporter
still functions using /host/root and /host/sys mounts; if a collector truly
requires host PID, add a short inline comment next to hostPID and a
justification in the PR describing why the exception is necessary and document
which collector needs it.
- Around line 27-96: Add resource limits and liveness/readiness probes for both
containers: for container "node-exporter" (name node-exporter) add
resources.limits for cpu and memory (e.g., match requests ratio like cpu: 50m,
memory: 64Mi) and add a readinessProbe and livenessProbe performing an HTTP GET
to path /metrics on port 9100 (scheme HTTP) with sensible timing
(initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold); for
container "kube-rbac-proxy" (name kube-rbac-proxy) add resources.limits (e.g.,
cpu: 50m, memory: 64Mi) and readinessProbe/livenessProbe using HTTP GET to path
/metrics on port 9101 but with scheme HTTPS (and tls settings honored) and
similar timing values; ensure these probe blocks are added under each container
and adjust values to match cluster SLOs.
- Around line 58-84: Update the kube-rbac-proxy container's securityContext to
harden the sidecar: add allowPrivilegeEscalation: false, set runAsNonRoot: true
and an explicit non-root runAsUser (choose a non-zero UID), and drop all Linux
capabilities (capabilities.drop: ["ALL"] and only add back any minimal
capability if proven necessary); keep readOnlyRootFilesystem: true and do not
change other mounts. Target the container named "kube-rbac-proxy" in the
DaemonSet spec when applying these changes.

In `@assets/optional/node-exporter/kustomization.aarch64.yaml`:
- Around line 1-7: Replace the placeholder digest values for the two images in
kustomization.aarch64.yaml: update the digest fields under the image entries for
"quay.io/openshift/node-exporter" and "quay.io/openshift/kube-rbac-proxy" with
the actual sha256 digests that correspond to the referenced newName images
(registry.redhat.io/openshift4/ose-prometheus-node-exporter-rhel9 and
registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9); obtain the exact
digests from your image registry (e.g., skopeo inspect or the registry API/CI
output) and commit those real sha256:... values in place of "sha256:placeholder"
so the aarch64 overlay pins to real images.

In `@packaging/observability/otelcol.d/microshift-metrics.yaml`:
- Around line 10-27: The HTTPS scrapes discovered via
kubernetes_sd_configs.role: endpoints will use pod IPs for TLS ServerName and
fail hostname verification; update the TLS config for the
prometheus/kube_state_metrics scrape (job_name: kube-state-metrics) and likewise
for prometheus/metrics_server to include tls_config.server_name set to the
service FQDN (for example kube-state-metrics.openshift-monitoring.svc) so
certificate hostname verification uses the service DNS name instead of the pod
IP; add tls_config.server_name alongside the existing ca_file entry under
prometheus/kube_state_metrics (and the equivalent block for
prometheus/metrics_server).

In `@pkg/healthcheck/microshift_optional_workloads.go`:
- Around line 42-53: The three manifest entries for openshift-monitoring are
clobbering each other because fillOptionalMicroShiftWorkloads() keeps a single
NamespaceWorkloads per namespace; update the initialization so entries that
target the same Namespace ("openshift-monitoring") are merged rather than
overwritten: when building the map of NamespaceWorkloads (type
NamespaceWorkloads) combine Deployments and DaemonSets arrays (e.g., merge
"metrics-server" and "kube-state-metrics" into Deployments and "node-exporter"
into DaemonSets) before assigning to the namespace key in
fillOptionalMicroShiftWorkloads(), ensuring duplicates are avoided.

In `@scripts/auto-rebase/rebase.sh`:
- Around line 1136-1159: The METRICS_JSON_MAP associative array currently misses
the kube-rbac-proxy entry, so update METRICS_JSON_MAP (declared as
METRICS_JSON_MAP=( ... )) to include a mapping for the kube-rbac-proxy image
(e.g., add ["kube_rbac_proxy"]="kube-rbac-proxy" or a consistent key name used
elsewhere), so the for-loop that iterates json_key/release_tag/new_image will
pick up and write kube-rbac-proxy into the generated
release-metrics-${arch}.json files the same way as
metrics_server/kube_state_metrics/node_exporter.

In `@scripts/devenv-builder/create-vm.sh`:
- Around line 58-63: The RHEL major detection in create-vm.sh uses grep -P with
a pattern that can fail under set -euo when VMNAME contains just "-10" (no dot),
causing the script to exit and BOOT_OPTS to never be set; change the logic to
robustly derive RHEL_MAJOR (prefer MICROSHIFT_RHEL_VERSION if present, otherwise
extract digits from VMNAME) and avoid grep failing on no-match (e.g., use grep
-oE '\d+' with a fallback like "|| true" or use pure shell parameter expansion
to strip the suffix and parse digits), then compute RHEL_MAJOR=${RHEL_MAJOR%%.*}
or cut -d. -f1 and keep the existing BOOT_OPTS assignment using that value.

---

Duplicate comments:
In `@assets/optional/metrics-server/release-metrics-aarch64.json`:
- Line 3: The JSON contains placeholder values ("base": "placeholder" and image
digests like sha256:placeholder) that must be populated from the OCP payload;
update the update_metrics_images() function so it reads the OCP payload during
the build, replaces the "base": "placeholder" field and any sha256:placeholder
digests in release-metrics-aarch64.json (and the other affected files) with the
actual values, and fail the build with a clear error if any placeholders remain
after processing to prevent deployment with placeholders.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@assets/optional/kube-state-metrics/01-cluster-role.yaml`:
- Around line 12-30: Remove cluster-wide secrets access from the ClusterRole by
deleting the "secrets" entry from the resources list in the Role/ClusterRole
definition (the block that currently lists configmaps, secrets, nodes, pods,
services, serviceaccounts, ...). Edit the resources array so it no longer
includes "secrets" (leaving other resources intact) to enforce least-privilege
RBAC for the kube-state-metrics exporter.

In `@assets/optional/kube-state-metrics/02-custom-resource-state-configmap.yaml`:
- Around line 417-470: The HELP texts for the metrics
verticalpodautoscaler_spec_resourcepolicy_container_policies_maxallowed_cpu and
verticalpodautoscaler_spec_resourcepolicy_container_policies_maxallowed_memory
are incorrect — they say "Minimum" but the metric exposes maxAllowed; update
both help strings to refer to "Maximum" (e.g., "Maximum cpu resources..." and
"Maximum memory resources...") so the Prometheus series are labeled correctly;
locate the help fields adjacent to those metric names and change the wording
accordingly.

In `@assets/optional/kube-state-metrics/03-deployment.yaml`:
- Around line 64-68: Update the pod-level securityContext and each container's
securityContext in the Deployment manifest (the pod spec and the three container
blocks shown around the empty securityContext entries) to enforce non-root and
hardened settings: set pod.securityContext.runAsNonRoot: true and a non-root
runAsUser (e.g., 1000) if not already set; for each container set
securityContext.runAsNonRoot: true, runAsUser consistent with the pod,
allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, privileged:
false, and capabilities.drop: ["ALL"] (and add only any minimal capabilities
required by that specific container); also add a seccompProfile: { type:
RuntimeDefault } at the pod or container level. Ensure these changes are applied
to the three container blocks and the pod-level securityContext referred to in
the diff.
- Around line 35-126: Add liveness and readiness probes plus CPU/memory limits
for each container: for the kube-state-metrics container (name:
kube-state-metrics) add an HTTPGet liveness and readiness probe targeting the
exporter on localhost:8081 (or the telemetry port 8082 if appropriate) with
sensible initialDelay/period/timeout, and add resources.limits.cpu and
resources.limits.memory alongside the existing requests; for the
kube-rbac-proxy-main and kube-rbac-proxy-self containers (names:
kube-rbac-proxy-main and kube-rbac-proxy-self) add liveness/readiness probes
(HTTPGet or TCP) pointing at their container ports 8443 and 9443 respectively
(use /healthz or /readyz or /metrics as appropriate) with sensible timing
values, and add matching resources.limits.cpu and resources.limits.memory for
each container to bound resource usage. Ensure probe fields and limits are added
under each container spec where args, image, name, and resources exist.

In `@assets/optional/node-exporter/03-daemonset.yaml`:
- Line 129: The DaemonSet sets hostPID: true which unnecessarily exposes the
host PID namespace; remove the hostPID: true line from the DaemonSet spec to
follow the guideline "No hostPID, hostNetwork, hostIPC, privileged: true", and
verify the exporter still works using the existing mounts (/host/root/proc and
/host/sys); only reintroduce hostPID if a specific collector explicitly requires
host PID visibility and document that requirement next to the hostPID setting.
- Around line 144-146: The init container "init-textfile" is unnecessarily
running privileged and as root; update its securityContext to remove privileged:
true and runAsUser: 0, and instead set runAsNonRoot: true, runAsUser to a
non-root UID (e.g., 1000) or remove runAsUser so the image defaults to non-root,
set readOnlyRootFilesystem: true, and allowPrivilegeEscalation: false; ensure no
hostPID/hostNetwork/hostIPC are enabled for that container and retain only the
minimal mounts (the emptyDir textfile and the read-only /var/log/wtmp) so the
init container is least-privileged.
- Around line 65-69: The node-exporter container currently has an empty
securityContext and no resource limits; update the container spec for
"node-exporter" to explicitly set securityContext: runAsNonRoot: true,
readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, and drop all
capabilities (capabilities: { drop: ["ALL"] }) then add back only the minimal
required capability if needed (e.g., NET_RAW) via add. Also add resource limits
to match requests (set resources.limits.cpu and resources.limits.memory
alongside the existing resources.requests.cpu and resources.requests.memory).
Ensure these changes are applied to the container entry named "node-exporter" in
the DaemonSet manifest.
- Around line 88-99: The kube-rbac-proxy daemonset currently sets
--secure-listen-address=[$(IP)]:9100 (and uses env name IP) while running with
hostNetwork: true, which binds to the node IP and is not reachable by the
collector that scrapes 127.0.0.1:9100; change the proxy to bind to loopback
instead or make the collector target the node IP. Concretely, in the DaemonSet
arguments for kube-rbac-proxy (the --secure-listen-address entry and the env
name: IP usage) replace binding to [$ (IP)] with 127.0.0.1:9100 (or remove the
envRef usage) so the proxy listens on localhost, or alternatively update the
collector scrape target to use the pod/node IP; apply the same fix for the
duplicated instance referenced around the second occurrence (lines noted in the
comment).

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@assets/optional/kube-state-metrics/03-deployment.yaml`:
- Around line 96-98: The TLS secret volume for kube-state-metrics is mounted
with readOnly: false; change the volumeMount for name: kube-state-metrics-tls
(mountPath: /etc/tls/private) to readOnly: true, and make the same change for
the other kube-state-metrics-tls mount instance referenced later in the file so
both secret mounts are read-only.

In `@assets/optional/node-exporter/03-daemonset.yaml`:
- Around line 121-124: The TLS secret volumeMount for the node-exporter
container is currently writable; change the volumeMount entry named
"node-exporter-tls" (mountPath "/etc/tls/private") to be readOnly: true so the
secret cannot be modified at runtime; update the volumeMount under the container
spec where "volumeMounts" contains name: node-exporter-tls and mountPath:
/etc/tls/private to set readOnly: true.